You'll be delighted to know that after an investigation I've abandoned the idea of using YAML, although I suspect the number of people who are relieved is far greater than the number of people who are surprised.
I've had a look at 31 config file parsers, and I think I'll go with Config::IniFiles, since it allows here docs, which are suitable for the extended comments we see in CHANGES files.
I'll standardize on the file name Changes.conf, which after an incomplete analysis (using Archive::Extract), I can see is not in use:
Frequencies:
CHANGE.LOG => 3.
CHANGELIST => 1.
CHANGELOG => 112.
CHANGES => 792.
CHANGES-1.0 => 1.
CHANGES-2.20 => 1.
CHANGES-2.22 => 1.
CHANGES-2.23 => 1.
CHANGES-3.00 => 3.
CHANGES-cp1251.txt => 1.
CHANGES.OLD => 1.
CHANGES.TXT => 1.
CHANGES.etext => 1.
CHANGES.html => 2.
CHANGES.mogilefsd => 1.
CHANGES.mogstored => 1.
CHANGES.old => 1.
CHANGES.pod => 3.
CHANGES.txt => 14.
CHANGE_LOG => 1.
Change.log => 3.
ChangeLog => 752.
ChangeLog-1-00-02 => 1.
ChangeLog-Perl-1-00-01 => 1.
ChangeLog.0 => 2.
ChangeLog.1 => 3.
ChangeLog.1x => 1.
ChangeLog.2 => 1.
ChangeLog.20 => 1.
ChangeLog.21 => 1.
ChangeLog.3 => 1.
ChangeLog.4 => 1.
ChangeLog.5 => 1.
ChangeLog.6 => 1.
ChangeLog.CVS => 1.
ChangeLog.CVS.delta => 1.
ChangeLog.SPOON => 2.
ChangeLog.d => 1.
ChangeLog.detailed => 2.
ChangeLog.old => 1.
ChangeLog.owen => 2.
ChangeLog.svn => 2.
ChangeLog.txt => 1.
ChangeLog.xml => 5.
ChangeLog~ => 1.
Changelog => 52.
Changes => 11503.
Changes-2.64 => 1.
Changes-darcs => 1.
Changes.0.46 => 1.
Changes.1 => 1.
Changes.Checker => 1.
Changes.DOM => 1.
Changes.XQL => 1.
Changes.bak => 1.
Changes.html => 3.
Changes.i18n => 1.
Changes.ja => 1.
Changes.old => 3.
Changes.pod => 10.
Changes.src => 2.
Changes.ttl => 4.
Changes.txt => 62.
Changes.ver0X => 1.
Changes.yml => 2.
Changes1.6 => 1.
Changes~ => 5.
changelog => 2.
changelog.html => 1.
changelog.txt => 1.
changes => 4.
changes.dat => 1.
changes.pod => 1.
changes.txt => 2.
changesrus.txt => 1.
changesrus_koi8.txt => 1.
As for the format, I'm thinking of:
[Killer::App]
1.02=2008-01-25T10:08:00
1.01=2008-01-25T10:08:00
1.00=2007-07-27T18:30:45
so the version numbers can be sorted by date to get the latest version, followed by one section per version:
[1.02]
lapsang suchong...
[1.01]
Lorem ipsum...
etc.
Re: changes.conf
Ron Savage on 2008-05-05T23:43:49
Hmmm, you make some good points.
I would argue that a change log supplies config info pertaining to each version, so the choice is not that bad. But I'll certainly reconsider. After all, nothing is cast in Perl-based stone just yet.
I would like an extension which definitively indicated the format, a la yml and xml, but without the format being known, that's not so easy.
Changelog.ini is reasonable. That sort of feedback is the point of posting in the first place.
The date can easily be a per-section entry, and used for sorting, which solves the little bit of unease I had over the all-dates-up-front idea.
Yes, I realize multi-value entries are problematic. Designing a file format requires balancing that issue against the difficulty beginners are always going to have writing correct YAML. Neither choice (not XML etc) is perfect, nor easy. The pre-existing resistance to YAML is also on my mind. I'm worried chosing YAML will lead to people feeling it's all too difficult, and hence falling back to something ad hoc (again).
As for using it outside of Perl, I'm hoping the formats I'm playing with will lead to one which can, at the very least, be easily extended to apply to other things, perhaps even the alien libraries underpinning the Alien::* modules.
